home *** CD-ROM | disk | FTP | other *** search
/ Amiga Plus 2004 #11 / Amiga Plus CD - 2004 - No. 11.iso / AmiSoft / Dev / gg / binutils-mo-bi.lha / info / configure.info-1 < prev    next >
Text File  |  2004-08-20  |  49KB  |  1,314 lines
  1. This is configure.info, produced by makeinfo version 4.2 from
  2. ./configure.texi.
  3.  
  4. INFO-DIR-SECTION GNU admin
  5. START-INFO-DIR-ENTRY
  6. * configure: (configure).    The GNU configure and build system
  7. END-INFO-DIR-ENTRY
  8.  
  9.    This file documents the GNU configure and build system.
  10.  
  11.    Copyright (C) 1998 Cygnus Solutions.
  12.  
  13.    Permission is granted to make and distribute verbatim copies of this
  14. manual provided the copyright notice and this permission notice are
  15. preserved on all copies.
  16.  
  17.    Permission is granted to copy and distribute modified versions of
  18. this manual under the conditions for verbatim copying, provided that
  19. the entire resulting derived work is distributed under the terms of a
  20. permission notice identical to this one.
  21.  
  22.    Permission is granted to copy and distribute translations of this
  23. manual into another language, under the above conditions for modified
  24. versions, except that this permission notice may be stated in a
  25. translation approved by the Foundation.
  26.  
  27. 
  28. File: configure.info,  Node: Top,  Next: Introduction,  Up: (dir)
  29.  
  30. GNU configure and build system
  31. ******************************
  32.  
  33.    The GNU configure and build system.
  34.  
  35. * Menu:
  36.  
  37. * Introduction::        Introduction.
  38. * Getting Started::        Getting Started.
  39. * Files::            Files.
  40. * Configuration Names::        Configuration Names.
  41. * Cross Compilation Tools::    Cross Compilation Tools.
  42. * Canadian Cross::        Canadian Cross.
  43. * Cygnus Configure::        Cygnus Configure.
  44. * Multilibs::            Multilibs.
  45. * FAQ::                Frequently Asked Questions.
  46. * Index::            Index.
  47.  
  48. 
  49. File: configure.info,  Node: Introduction,  Next: Getting Started,  Prev: Top,  Up: Top
  50.  
  51. Introduction
  52. ************
  53.  
  54.    This document describes the GNU configure and build systems.  It
  55. describes how autoconf, automake, libtool, and make fit together.  It
  56. also includes a discussion of the older Cygnus configure system.
  57.  
  58.    This document does not describe in detail how to use each of the
  59. tools; see the respective manuals for that.  Instead, it describes
  60. which files the developer must write, which files are machine generated
  61. and how they are generated, and where certain common problems should be
  62. addressed.
  63.  
  64.    This document draws on several sources, including the autoconf
  65. manual by David MacKenzie (*note autoconf overview: (autoconf)Top.),
  66. the automake manual by David MacKenzie and Tom Tromey (*note automake
  67. overview: (automake)Top.), the libtool manual by Gordon Matzigkeit
  68. (*note libtool overview: (libtool)Top.), and the Cygnus configure
  69. manual by K. Richard Pixley.
  70.  
  71. * Menu:
  72.  
  73. * Goals::            Goals.
  74. * Tools::            The tools.
  75. * History::            History.
  76. * Building::            Building.
  77.  
  78. 
  79. File: configure.info,  Node: Goals,  Next: Tools,  Up: Introduction
  80.  
  81. Goals
  82. =====
  83.  
  84.    The GNU configure and build system has two main goals.
  85.  
  86.    The first is to simplify the development of portable programs.  The
  87. system permits the developer to concentrate on writing the program,
  88. simplifying many details of portability across Unix and even Windows
  89. systems, and permitting the developer to describe how to build the
  90. program using simple rules rather than complex Makefiles.
  91.  
  92.    The second is to simplify the building of programs distributed as
  93. source code.  All programs are built using a simple, standardized, two
  94. step process.  The program builder need not install any special tools in
  95. order to build the program.
  96.  
  97. 
  98. File: configure.info,  Node: Tools,  Next: History,  Prev: Goals,  Up: Introduction
  99.  
  100. Tools
  101. =====
  102.  
  103.    The GNU configure and build system is comprised of several different
  104. tools.  Program developers must build and install all of these tools.
  105.  
  106.    People who just want to build programs from distributed sources
  107. normally do not need any special tools beyond a Unix shell, a make
  108. program, and a C compiler.
  109.  
  110. autoconf
  111.      provides a general portability framework, based on testing the
  112.      features of the host system at build time.
  113.  
  114. automake
  115.      a system for describing how to build a program, permitting the
  116.      developer to write a simplified `Makefile'.
  117.  
  118. libtool
  119.      a standardized approach to building shared libraries.
  120.  
  121. gettext
  122.      provides a framework for translation of text messages into other
  123.      languages; not really discussed in this document.
  124.  
  125. m4
  126.      autoconf requires the GNU version of m4; the standard Unix m4 does
  127.      not suffice.
  128.  
  129. perl
  130.      automake requires perl.
  131.  
  132. 
  133. File: configure.info,  Node: History,  Next: Building,  Prev: Tools,  Up: Introduction
  134.  
  135. History
  136. =======
  137.  
  138.    This is a very brief and probably inaccurate history.
  139.  
  140.    As the number of Unix variants increased during the 1980s, it became
  141. harder to write programs which could run on all variants.  While it was
  142. often possible to use `#ifdef' to identify particular systems,
  143. developers frequently did not have access to every system, and the
  144. characteristics of some systems changed from version to version.
  145.  
  146.    By 1992, at least three different approaches had been developed:
  147.    * The Metaconfig program, by Larry Wall, Harlan Stenn, and Raphael
  148.      Manfredi.
  149.  
  150.    * The Cygnus configure script, by K. Richard Pixley, and the gcc
  151.      configure script, by Richard Stallman.  These use essentially the
  152.      same approach, and the developers communicated regularly.
  153.  
  154.    * The autoconf program, by David MacKenzie.
  155.  
  156.    The Metaconfig program is still used for Perl and a few other
  157. programs.  It is part of the Dist package.  I do not know if it is
  158. being developed.
  159.  
  160.    In 1994, David MacKenzie and others modified autoconf to incorporate
  161. all the features of Cygnus configure.  Since then, there has been a
  162. slow but steady conversion of GNU programs from Cygnus configure to
  163. autoconf. gcc has been converted, eliminating the gcc configure script.
  164.  
  165.    GNU autoconf was regularly maintained until late 1996.  As of this
  166. writing in June, 1998, it has no public maintainer.
  167.  
  168.    Most programs are built using the make program, which requires the
  169. developer to write Makefiles describing how to build the programs.
  170. Since most programs are built in pretty much the same way, this led to a
  171. lot of duplication.
  172.  
  173.    The X Window system is built using the imake tool, which uses a
  174. database of rules to eliminate the duplication.  However, building a
  175. tool which was developed using imake requires that the builder have
  176. imake installed, violating one of the goals of the GNU system.
  177.  
  178.    The new BSD make provides a standard library of Makefile fragments,
  179. which permits developers to write very simple Makefiles.  However, this
  180. requires that the builder install the new BSD make program.
  181.  
  182.    In 1994, David MacKenzie wrote the first version of automake, which
  183. permitted writing a simple build description which was converted into a
  184. Makefile which could be used by the standard make program.  In 1995, Tom
  185. Tromey completely rewrote automake in Perl, and he continues to enhance
  186. it.
  187.  
  188.    Various free packages built libraries, and by around 1995 several
  189. included support to build shared libraries on various platforms.
  190. However, there was no consistent approach.  In early 1996, Gordon
  191. Matzigkeit began working on libtool, which provided a standardized
  192. approach to building shared libraries.  This was integrated into
  193. automake from the start.
  194.  
  195.    The development of automake and libtool was driven by the GNITS
  196. project, a group of GNU maintainers who designed standardized tools to
  197. help meet the GNU coding standards.
  198.  
  199. 
  200. File: configure.info,  Node: Building,  Prev: History,  Up: Introduction
  201.  
  202. Building
  203. ========
  204.  
  205.    Most readers of this document should already know how to build a
  206. tool by running `configure' and `make'.  This section may serve as a
  207. quick introduction or reminder.
  208.  
  209.    Building a tool is normally as simple as running `configure'
  210. followed by `make'.  You should normally run `configure' from an empty
  211. directory, using some path to refer to the `configure' script in the
  212. source directory.  The directory in which you run `configure' is called
  213. the "object directory".
  214.  
  215.    In order to use a object directory which is different from the source
  216. directory, you must be using the GNU version of `make', which has the
  217. required `VPATH' support.  Despite this restriction, using a different
  218. object directory is highly recommended:
  219.    * It keeps the files generated during the build from cluttering up
  220.      your sources.
  221.  
  222.    * It permits you to remove the built files by simply removing the
  223.      entire build directory.
  224.  
  225.    * It permits you to build from the same sources with several sets of
  226.      configure options simultaneously.
  227.  
  228.    If you don't have GNU `make', you will have to run `configure' in
  229. the source directory.  All GNU packages should support this; in
  230. particular, GNU packages should not assume the presence of GNU `make'.
  231.  
  232.    After running `configure', you can build the tools by running `make'.
  233.  
  234.    To install the tools, run `make install'.  Installing the tools will
  235. copy the programs and any required support files to the "installation
  236. directory".  The location of the installation directory is controlled
  237. by `configure' options, as described below.
  238.  
  239.    In the Cygnus tree at present, the info files are built and
  240. installed as a separate step.  To build them, run `make info'.  To
  241. install them, run `make install-info'.
  242.  
  243.    All `configure' scripts support a wide variety of options.  The most
  244. interesting ones are `--with' and `--enable' options which are
  245. generally specific to particular tools.  You can usually use the
  246. `--help' option to get a list of interesting options for a particular
  247. configure script.
  248.  
  249.    The only generic options you are likely to use are the `--prefix'
  250. and `--exec-prefix' options.  These options are used to specify the
  251. installation directory.
  252.  
  253.    The directory named by the `--prefix' option will hold machine
  254. independent files such as info files.
  255.  
  256.    The directory named by the `--exec-prefix' option, which is normally
  257. a subdirectory of the `--prefix' directory, will hold machine dependent
  258. files such as executables.
  259.  
  260.    The default for `--prefix' is `/usr/local'.  The default for
  261. `--exec-prefix' is the value used for `--prefix'.
  262.  
  263.    The convention used in Cygnus releases is to use a `--prefix' option
  264. of `/usr/cygnus/RELEASE', where RELEASE is the name of the release, and
  265. to use a `--exec-prefix' option of `/usr/cygnus/RELEASE/H-HOST', where
  266. HOST is the configuration name of the host system (*note Configuration
  267. Names::).
  268.  
  269.    Do not use either the source or the object directory as the
  270. installation directory.  That will just lead to confusion.
  271.  
  272. 
  273. File: configure.info,  Node: Getting Started,  Next: Files,  Prev: Introduction,  Up: Top
  274.  
  275. Getting Started
  276. ***************
  277.  
  278.    To start using the GNU configure and build system with your software
  279. package, you must write three files, and you must run some tools to
  280. manually generate additional files.
  281.  
  282. * Menu:
  283.  
  284. * Write configure.in::        Write configure.in.
  285. * Write Makefile.am::        Write Makefile.am.
  286. * Write acconfig.h::        Write acconfig.h.
  287. * Generate files::        Generate files.
  288. * Getting Started Example::    Example.
  289.  
  290. 
  291. File: configure.info,  Node: Write configure.in,  Next: Write Makefile.am,  Up: Getting Started
  292.  
  293. Write configure.in
  294. ==================
  295.  
  296.    You must first write the file `configure.in'.  This is an autoconf
  297. input file, and the autoconf manual describes in detail what this file
  298. should look like.
  299.  
  300.    You will write tests in your `configure.in' file to check for
  301. conditions that may change from one system to another, such as the
  302. presence of particular header files or functions.
  303.  
  304.    For example, not all systems support the `gettimeofday' function.
  305. If you want to use the `gettimeofday' function when it is available,
  306. and to use some other function when it is not, you would check for this
  307. by putting `AC_CHECK_FUNCS(gettimeofday)' in `configure.in'.
  308.  
  309.    When the configure script is run at build time, this will arrange to
  310. define the preprocessor macro `HAVE_GETTIMEOFDAY' to the value 1 if the
  311. `gettimeofday' function is available, and to not define the macro at
  312. all if the function is not available.  Your code can then use `#ifdef'
  313. to test whether it is safe to call `gettimeofday'.
  314.  
  315.    If you have an existing body of code, the `autoscan' program may
  316. help identify potential portability problems, and hence configure tests
  317. that you will want to use.  *Note Invoking autoscan: (autoconf)Invoking
  318. autoscan.
  319.  
  320.    Another handy tool for an existing body of code is `ifnames'.  This
  321. will show you all the preprocessor conditionals that the code already
  322. uses.  *Note Invoking ifnames: (autoconf)Invoking ifnames.
  323.  
  324.    Besides the portability tests which are specific to your particular
  325. package, every `configure.in' file should contain the following macros.
  326.  
  327. `AC_INIT'
  328.      This macro takes a single argument, which is the name of a file in
  329.      your package.  For example, `AC_INIT(foo.c)'.
  330.  
  331. `AC_PREREQ(VERSION)'
  332.      This macro is optional.  It may be used to indicate the version of
  333.      `autoconf' that you are using.  This will prevent users from
  334.      running an earlier version of `autoconf' and perhaps getting an
  335.      invalid `configure' script.  For example, `AC_PREREQ(2.12)'.
  336.  
  337. `AM_INIT_AUTOMAKE'
  338.      This macro takes two arguments: the name of the package, and a
  339.      version number.  For example, `AM_INIT_AUTOMAKE(foo, 1.0)'.  (This
  340.      macro is not needed if you are not using automake).
  341.  
  342. `AM_CONFIG_HEADER'
  343.      This macro names the header file which will hold the preprocessor
  344.      macro definitions at run time.  Normally this should be
  345.      `config.h'.  Your sources would then use `#include "config.h"' to
  346.      include it.
  347.  
  348.      This macro may optionally name the input file for that header
  349.      file; by default, this is `config.h.in', but that file name works
  350.      poorly on DOS filesystems.  Therefore, it is often better to name
  351.      it explicitly as `config.in'.
  352.  
  353.      This is what you should normally put in `configure.in':
  354.           AM_CONFIG_HEADER(config.h:config.in)
  355.  
  356.      (If you are not using automake, use `AC_CONFIG_HEADER' rather than
  357.      `AM_CONFIG_HEADER').
  358.  
  359. `AM_MAINTAINER_MODE'
  360.      This macro always appears in Cygnus configure scripts.  Other
  361.      programs may or may not use it.
  362.  
  363.      If this macro is used, the `--enable-maintainer-mode' option is
  364.      required to enable automatic rebuilding of generated files used by
  365.      the configure system.  This of course requires that developers be
  366.      aware of, and use, that option.
  367.  
  368.      If this macro is not used, then the generated files will always be
  369.      rebuilt automatically.  This will cause problems if the wrong
  370.      versions of autoconf, automake, or others are in the builder's
  371.      `PATH'.
  372.  
  373.      (If you are not using automake, you do not need to use this macro).
  374.  
  375. `AC_EXEEXT'
  376.      Either this macro or `AM_EXEEXT' always appears in Cygnus configure
  377.      files.  Other programs may or may not use one of them.
  378.  
  379.      This macro looks for the executable suffix used on the host
  380.      system.  On Unix systems, this is the empty string.  On Windows
  381.      systems, this is `.exe'.  This macro directs automake to use the
  382.      executable suffix as appropriate when creating programs.  This
  383.      macro does not take any arguments.
  384.  
  385.      The `AC_EXEEXT' form is new, and is part of a Cygnus patch to
  386.      autoconf to support compiling with Visual C++.  Older programs use
  387.      `AM_EXEEXT' instead.
  388.  
  389.      (Programs which do not use automake use neither `AC_EXEEXT' nor
  390.      `AM_EXEEXT').
  391.  
  392. `AC_PROG_CC'
  393.      If you are writing C code, you will normally want to use this
  394.      macro.  It locates the C compiler to use.  It does not take any
  395.      arguments.
  396.  
  397.      However, if this `configure.in' file is for a library which is to
  398.      be compiled by a cross compiler which may not fully work, then you
  399.      will not want to use `AC_PROG_CC'.  Instead, you will want to use a
  400.      variant which does not call the macro `AC_PROG_CC_WORKS'.  Examples
  401.      can be found in various `configure.in' files for libraries that are
  402.      compiled with cross compilers, such as libiberty or libgloss.
  403.      This is essentially a bug in autoconf, and there will probably be
  404.      a better workaround at some point.
  405.  
  406. `AC_PROG_CXX'
  407.      If you are writing C++ code, you will want to use this macro.  It
  408.      locates the C++ compiler to use.  It does not take any arguments.
  409.      The same cross compiler comments apply as for `AC_PROG_CC'.
  410.  
  411. `AM_PROG_LIBTOOL'
  412.      If you want to build libraries, and you want to permit them to be
  413.      shared, or you want to link against libraries which were built
  414.      using libtool, then you will need this macro.  This macro is
  415.      required in order to use libtool.
  416.  
  417.      By default, this will cause all libraries to be built as shared
  418.      libraries.  To prevent this-to change the default-use
  419.      `AM_DISABLE_SHARED' before `AM_PROG_LIBTOOL'.  The configure
  420.      options `--enable-shared' and `--disable-shared' may be used to
  421.      override the default at build time.
  422.  
  423. `AC_DEFINE(_GNU_SOURCE)'
  424.      GNU packages should normally include this line before any other
  425.      feature tests.  This defines the macro `_GNU_SOURCE' when
  426.      compiling, which directs the libc header files to provide the
  427.      standard GNU system interfaces including all GNU extensions.  If
  428.      this macro is not defined, certain GNU extensions may not be
  429.      available.
  430.  
  431. `AC_OUTPUT'
  432.      This macro takes a list of file names which the configure process
  433.      should produce.  This is normally a list of one or more `Makefile'
  434.      files in different directories.  If your package lives entirely in
  435.      a single directory, you would use simply `AC_OUTPUT(Makefile)'.
  436.      If you also have, for example, a `lib' subdirectory, you would use
  437.      `AC_OUTPUT(Makefile lib/Makefile)'.
  438.  
  439.    If you want to use locally defined macros in your `configure.in'
  440. file, then you will need to write a `acinclude.m4' file which defines
  441. them (if not using automake, this file is called `aclocal.m4').
  442. Alternatively, you can put separate macros in an `m4' subdirectory, and
  443. put `ACLOCAL_AMFLAGS = -I m4' in your `Makefile.am' file so that the
  444. `aclocal' program will be able to find them.
  445.  
  446.    The different macro prefixes indicate which tool defines the macro.
  447. Macros which start with `AC_' are part of autoconf.  Macros which start
  448. with `AM_' are provided by automake or libtool.
  449.  
  450. 
  451. File: configure.info,  Node: Write Makefile.am,  Next: Write acconfig.h,  Prev: Write configure.in,  Up: Getting Started
  452.  
  453. Write Makefile.am
  454. =================
  455.  
  456.    You must write the file `Makefile.am'.  This is an automake input
  457. file, and the automake manual describes in detail what this file should
  458. look like.
  459.  
  460.    The automake commands in `Makefile.am' mostly look like variable
  461. assignments in a `Makefile'.  automake recognizes special variable
  462. names, and automatically add make rules to the output as needed.
  463.  
  464.    There will be one `Makefile.am' file for each directory in your
  465. package.  For each directory with subdirectories, the `Makefile.am'
  466. file should contain the line
  467.      SUBDIRS = DIR DIR ...
  468.  
  469. where each DIR is the name of a subdirectory.
  470.  
  471.    For each `Makefile.am', there should be a corresponding `Makefile'
  472. in the `AC_OUTPUT' macro in `configure.in'.
  473.  
  474.    Every `Makefile.am' written at Cygnus should contain the line
  475.      AUTOMAKE_OPTIONS = cygnus
  476.  
  477. This puts automake into Cygnus mode.  See the automake manual for
  478. details.
  479.  
  480.    You may to include the version number of `automake' that you are
  481. using on the `AUTOMAKE_OPTIONS' line.  For example,
  482.      AUTOMAKE_OPTIONS = cygnus 1.3
  483.  
  484. This will prevent users from running an earlier version of `automake'
  485. and perhaps getting an invalid `Makefile.in'.
  486.  
  487.    If your package builds a program, then in the directory where that
  488. program is built you will normally want a line like
  489.      bin_PROGRAMS = PROGRAM
  490.  
  491. where PROGRAM is the name of the program.  You will then want a line
  492. like
  493.      PROGRAM_SOURCES = FILE FILE ...
  494.  
  495. where each FILE is the name of a source file to link into the program
  496. (e.g., `foo.c').
  497.  
  498.    If your package builds a library, and you do not want the library to
  499. ever be built as a shared library, then in the directory where that
  500. library is built you will normally want a line like
  501.      lib_LIBRARIES = libNAME.a
  502.  
  503. where `libNAME.a' is the name of the library.  You will then want a
  504. line like
  505.      libNAME_a_SOURCES = FILE FILE ...
  506.  
  507. where each FILE is the name of a source file to add to the library.
  508.  
  509.    If your package builds a library, and you want to permit building the
  510. library as a shared library, then in the directory where that library is
  511. built you will normally want a line like
  512.      lib_LTLIBRARIES = libNAME.la
  513.    The use of `LTLIBRARIES', and the `.la' extension, indicate a
  514. library to be built using libtool.  As usual, you will then want a line
  515. like
  516.      libNAME_la_SOURCES = FILE FILE ...
  517.  
  518.    The strings `bin' and `lib' that appear above in `bin_PROGRAMS' and
  519. `lib_LIBRARIES' are not arbitrary.  They refer to particular
  520. directories, which may be set by the `--bindir' and `--libdir' options
  521. to `configure'.  If those options are not used, the default values are
  522. based on the `--prefix' or `--exec-prefix' options to `configure'.  It
  523. is possible to use other names if the program or library should be
  524. installed in some other directory.
  525.  
  526.    The `Makefile.am' file may also contain almost anything that may
  527. appear in a normal `Makefile'.  automake also supports many other
  528. special variables, as well as conditionals.
  529.  
  530.    See the automake manual for more information.
  531.  
  532. 
  533. File: configure.info,  Node: Write acconfig.h,  Next: Generate files,  Prev: Write Makefile.am,  Up: Getting Started
  534.  
  535. Write acconfig.h
  536. ================
  537.  
  538.    If you are generating a portability header file, (i.e., you are using
  539. `AM_CONFIG_HEADER' in `configure.in'), then you will have to write a
  540. `acconfig.h' file.  It will have to contain the following lines.
  541.  
  542.      /* Name of package.  */
  543.      #undef PACKAGE
  544.      
  545.      /* Version of package.  */
  546.      #undef VERSION
  547.  
  548.    This requirement is really a bug in the system, and the requirement
  549. may be eliminated at some later date.
  550.  
  551.    The `acconfig.h' file will also similar comment and `#undef' lines
  552. for any unusual macros in the `configure.in' file, including any macro
  553. which appears in a `AC_DEFINE' macro.
  554.  
  555.    In particular, if you are writing a GNU package and therefore include
  556. `AC_DEFINE(_GNU_SOURCE)' in `configure.in' as suggested above, you will
  557. need lines like this in `acconfig.h':
  558.      /* Enable GNU extensions.  */
  559.      #undef _GNU_SOURCE
  560.  
  561.    Normally the `autoheader' program will inform you of any such
  562. requirements by printing an error message when it is run.  However, if
  563. you do anything particular odd in your `configure.in' file, you will
  564. have to make sure that the right entries appear in `acconfig.h', since
  565. otherwise the results of the tests may not be available in the
  566. `config.h' file which your code will use.
  567.  
  568.    (Thee `PACKAGE' and `VERSION' lines are not required if you are not
  569. using automake, and in that case you may not need a `acconfig.h' file
  570. at all).
  571.  
  572. 
  573. File: configure.info,  Node: Generate files,  Next: Getting Started Example,  Prev: Write acconfig.h,  Up: Getting Started
  574.  
  575. Generate files
  576. ==============
  577.  
  578.    Once you have written `configure.in', `Makefile.am', `acconfig.h',
  579. and possibly `acinclude.m4', you must use autoconf and automake
  580. programs to produce the first versions of the generated files.  This is
  581. done by executing the following sequence of commands.
  582.  
  583.      aclocal
  584.      autoconf
  585.      autoheader
  586.      automake
  587.  
  588.    The `aclocal' and `automake' commands are part of the automake
  589. package, and the `autoconf' and `autoheader' commands are part of the
  590. autoconf package.
  591.  
  592.    If you are using a `m4' subdirectory for your macros, you will need
  593. to use the `-I m4' option when you run `aclocal'.
  594.  
  595.    If you are not using the Cygnus tree, use the `-a' option when
  596. running `automake' command in order to copy the required support files
  597. into your source directory.
  598.  
  599.    If you are using libtool, you must build and install the libtool
  600. package with the same `--prefix' and `--exec-prefix' options as you
  601. used with the autoconf and automake packages.  You must do this before
  602. running any of the above commands.  If you are not using the Cygnus
  603. tree, you will need to run the `libtoolize' program to copy the libtool
  604. support files into your directory.
  605.  
  606.    Once you have managed to run these commands without getting any
  607. errors, you should create a new empty directory, and run the `configure'
  608. script which will have been created by `autoconf' with the
  609. `--enable-maintainer-mode' option.  This will give you a set of
  610. Makefiles which will include rules to automatically rebuild all the
  611. generated files.
  612.  
  613.    After doing that, whenever you have changed some of the input files
  614. and want to regenerated the other files, go to your object directory
  615. and run `make'.  Doing this is more reliable than trying to rebuild the
  616. files manually, because there are complex order dependencies and it is
  617. easy to forget something.
  618.  
  619. 
  620. File: configure.info,  Node: Getting Started Example,  Prev: Generate files,  Up: Getting Started
  621.  
  622. Example
  623. =======
  624.  
  625.    Let's consider a trivial example.
  626.  
  627.    Suppose we want to write a simple version of `touch'.  Our program,
  628. which we will call `poke', will take a single file name argument, and
  629. use the `utime' system call to set the modification and access times of
  630. the file to the current time.  We want this program to be highly
  631. portable.
  632.  
  633.    We'll first see what this looks like without using autoconf and
  634. automake, and then see what it looks like with them.
  635.  
  636. * Menu:
  637.  
  638. * Getting Started Example 1::        First Try.
  639. * Getting Started Example 2::        Second Try.
  640. * Getting Started Example 3::        Third Try.
  641. * Generate Files in Example::        Generate Files.
  642.  
  643. 
  644. File: configure.info,  Node: Getting Started Example 1,  Next: Getting Started Example 2,  Up: Getting Started Example
  645.  
  646. First Try
  647. ---------
  648.  
  649.    Here is our first try at `poke.c'.  Note that we've written it
  650. without ANSI/ISO C prototypes, since we want it to be highly portable.
  651.  
  652.      #include <stdio.h>
  653.      #include <stdlib.h>
  654.      #include <sys/types.h>
  655.      #include <utime.h>
  656.      
  657.      int
  658.      main (argc, argv)
  659.           int argc;
  660.           char **argv;
  661.      {
  662.        if (argc != 2)
  663.          {
  664.            fprintf (stderr, "Usage: poke file\n");
  665.            exit (1);
  666.          }
  667.      
  668.        if (utime (argv[1], NULL) < 0)
  669.          {
  670.            perror ("utime");
  671.            exit (1);
  672.          }
  673.      
  674.        exit (0);
  675.      }
  676.  
  677.    We also write a simple `Makefile'.
  678.  
  679.      CC = gcc
  680.      CFLAGS = -g -O2
  681.      
  682.      all: poke
  683.      
  684.      poke: poke.o
  685.          $(CC) -o poke $(CFLAGS) $(LDFLAGS) poke.o
  686.  
  687.    So far, so good.
  688.  
  689.    Unfortunately, there are a few problems.
  690.  
  691.    On older Unix systems derived from BSD 4.3, the `utime' system call
  692. does not accept a second argument of `NULL'.  On those systems, we need
  693. to pass a pointer to `struct utimbuf' structure.  Unfortunately, even
  694. older systems don't define that structure; on those systems, we need to
  695. pass an array of two `long' values.
  696.  
  697.    The header file `stdlib.h' was invented by ANSI C, and older systems
  698. don't have a copy.  We included it above to get a declaration of `exit'.
  699.  
  700.    We can find some of these portability problems by running
  701. `autoscan', which will create a `configure.scan' file which we can use
  702. as a prototype for our `configure.in' file.  I won't show the output,
  703. but it will notice the potential problems with `utime' and `stdlib.h'.
  704.  
  705.    In our `Makefile', we don't provide any way to install the program.
  706. This doesn't matter much for such a simple example, but a real program
  707. will need an `install' target.  For that matter, we will also want a
  708. `clean' target.
  709.  
  710. 
  711. File: configure.info,  Node: Getting Started Example 2,  Next: Getting Started Example 3,  Prev: Getting Started Example 1,  Up: Getting Started Example
  712.  
  713. Second Try
  714. ----------
  715.  
  716.    Here is our second try at this program.
  717.  
  718.    We modify `poke.c' to use preprocessor macros to control what
  719. features are available.  (I've cheated a bit by using the same macro
  720. names which autoconf will use).
  721.  
  722.      #include <stdio.h>
  723.      
  724.      #ifdef STDC_HEADERS
  725.      #include <stdlib.h>
  726.      #endif
  727.      
  728.      #include <sys/types.h>
  729.      
  730.      #ifdef HAVE_UTIME_H
  731.      #include <utime.h>
  732.      #endif
  733.      
  734.      #ifndef HAVE_UTIME_NULL
  735.      
  736.      #include <time.h>
  737.      
  738.      #ifndef HAVE_STRUCT_UTIMBUF
  739.      
  740.      struct utimbuf
  741.      {
  742.        long actime;
  743.        long modtime;
  744.      };
  745.      
  746.      #endif
  747.      
  748.      static int
  749.      utime_now (file)
  750.           char *file;
  751.      {
  752.        struct utimbuf now;
  753.      
  754.        now.actime = now.modtime = time (NULL);
  755.        return utime (file, &now);
  756.      }
  757.      
  758.      #define utime(f, p) utime_now (f)
  759.      
  760.      #endif /* HAVE_UTIME_NULL  */
  761.      
  762.      int
  763.      main (argc, argv)
  764.           int argc;
  765.           char **argv;
  766.      {
  767.        if (argc != 2)
  768.          {
  769.            fprintf (stderr, "Usage: poke file\n");
  770.            exit (1);
  771.          }
  772.      
  773.        if (utime (argv[1], NULL) < 0)
  774.          {
  775.            perror ("utime");
  776.            exit (1);
  777.          }
  778.      
  779.        exit (0);
  780.      }
  781.  
  782.    Here is the associated `Makefile'.  We've added support for the
  783. preprocessor flags we use.  We've also added `install' and `clean'
  784. targets.
  785.  
  786.      # Set this to your installation directory.
  787.      bindir = /usr/local/bin
  788.      
  789.      # Uncomment this if you have the standard ANSI/ISO C header files.
  790.      # STDC_HDRS = -DSTDC_HEADERS
  791.      
  792.      # Uncomment this if you have utime.h.
  793.      # UTIME_H = -DHAVE_UTIME_H
  794.      
  795.      # Uncomment this if utime (FILE, NULL) works on your system.
  796.      # UTIME_NULL = -DHAVE_UTIME_NULL
  797.      
  798.      # Uncomment this if struct utimbuf is defined in utime.h.
  799.      # UTIMBUF = -DHAVE_STRUCT_UTIMBUF
  800.      
  801.      CC = gcc
  802.      CFLAGS = -g -O2
  803.      
  804.      ALL_CFLAGS = $(STDC_HDRS) $(UTIME_H) $(UTIME_NULL) $(UTIMBUF) $(CFLAGS)
  805.      
  806.      all: poke
  807.      
  808.      poke: poke.o
  809.          $(CC) -o poke $(ALL_CFLAGS) $(LDFLAGS) poke.o
  810.      
  811.      .c.o:
  812.          $(CC) -c $(ALL_CFLAGS) poke.c
  813.      
  814.      install: poke
  815.          cp poke $(bindir)/poke
  816.      
  817.      clean:
  818.          rm poke poke.o
  819.  
  820.    Some problems with this approach should be clear.
  821.  
  822.    Users who want to compile poke will have to know how `utime' works
  823. on their systems, so that they can uncomment the `Makefile' correctly.
  824.  
  825.    The installation is done using `cp', but many systems have an
  826. `install' program which may be used, and which supports optional
  827. features such as stripping debugging information out of the installed
  828. binary.
  829.  
  830.    The use of `Makefile' variables like `CC', `CFLAGS' and `LDFLAGS'
  831. follows the requirements of the GNU standards.  This is convenient for
  832. all packages, since it reduces surprises for users.  However, it is
  833. easy to get the details wrong, and wind up with a slightly nonstandard
  834. distribution.
  835.  
  836. 
  837. File: configure.info,  Node: Getting Started Example 3,  Next: Generate Files in Example,  Prev: Getting Started Example 2,  Up: Getting Started Example
  838.  
  839. Third Try
  840. ---------
  841.  
  842.    For our third try at this program, we will write a `configure.in'
  843. script to discover the configuration features on the host system, rather
  844. than requiring the user to edit the `Makefile'.  We will also write a
  845. `Makefile.am' rather than a `Makefile'.
  846.  
  847.    The only change to `poke.c' is to add a line at the start of the
  848. file:
  849.      #include "config.h"
  850.  
  851.    The new `configure.in' file is as follows.
  852.  
  853.      AC_INIT(poke.c)
  854.      AM_INIT_AUTOMAKE(poke, 1.0)
  855.      AM_CONFIG_HEADER(config.h:config.in)
  856.      AC_PROG_CC
  857.      AC_HEADER_STDC
  858.      AC_CHECK_HEADERS(utime.h)
  859.      AC_EGREP_HEADER(utimbuf, utime.h, AC_DEFINE(HAVE_STRUCT_UTIMBUF))
  860.      AC_FUNC_UTIME_NULL
  861.      AC_OUTPUT(Makefile)
  862.  
  863.    The first four macros in this file, and the last one, were described
  864. above; see *Note Write configure.in::.  If we omit these macros, then
  865. when we run `automake' we will get a reminder that we need them.
  866.  
  867.    The other macros are standard autoconf macros.
  868.  
  869. `AC_HEADER_STDC'
  870.      Check for standard C headers.
  871.  
  872. `AC_CHECK_HEADERS'
  873.      Check whether a particular header file exists.
  874.  
  875. `AC_EGREP_HEADER'
  876.      Check for a particular string in a particular header file, in this
  877.      case checking for `utimbuf' in `utime.h'.
  878.  
  879. `AC_FUNC_UTIME_NULL'
  880.      Check whether `utime' accepts a NULL second argument to set the
  881.      file change time to the current time.
  882.  
  883.    See the autoconf manual for a more complete description.
  884.  
  885.    The new `Makefile.am' file is as follows.  Note how simple this is
  886. compared to our earlier `Makefile'.
  887.  
  888.      bin_PROGRAMS = poke
  889.      
  890.      poke_SOURCES = poke.c
  891.  
  892.    This means that we should build a single program name `poke'.  It
  893. should be installed in the binary directory, which we called `bindir'
  894. earlier.  The program `poke' is built from the source file `poke.c'.
  895.  
  896.    We must also write a `acconfig.h' file.  Besides `PACKAGE' and
  897. `VERSION', which must be mentioned for all packages which use automake,
  898. we must include `HAVE_STRUCT_UTIMBUF', since we mentioned it in an
  899. `AC_DEFINE'.
  900.  
  901.      /* Name of package.  */
  902.      #undef PACKAGE
  903.      
  904.      /* Version of package.  */
  905.      #undef VERSION
  906.      
  907.      /* Whether utime.h defines struct utimbuf.  */
  908.      #undef HAVE_STRUCT_UTIMBUF
  909.  
  910. 
  911. File: configure.info,  Node: Generate Files in Example,  Prev: Getting Started Example 3,  Up: Getting Started Example
  912.  
  913. Generate Files
  914. --------------
  915.  
  916.    We must now generate the other files, using the following commands.
  917.  
  918.      aclocal
  919.      autoconf
  920.      autoheader
  921.      automake
  922.  
  923.    When we run `autoheader', it will remind us of any macros we forgot
  924. to add to `acconfig.h'.
  925.  
  926.    When we run `automake', it will want to add some files to our
  927. distribution.  It will add them automatically if we use the
  928. `--add-missing' option.
  929.  
  930.    By default, `automake' will run in GNU mode, which means that it
  931. will want us to create certain additional files; as of this writing, it
  932. will want `NEWS', `README', `AUTHORS', and `ChangeLog', all of which
  933. are files which should appear in a standard GNU distribution.  We can
  934. either add those files, or run `automake' with the `--foreign' option.
  935.  
  936.    Running these tools will generate the following files, all of which
  937. are described in the next chapter.
  938.  
  939.    * `aclocal.m4'
  940.  
  941.    * `configure'
  942.  
  943.    * `config.in'
  944.  
  945.    * `Makefile.in'
  946.  
  947.    * `stamp-h.in'
  948.  
  949. 
  950. File: configure.info,  Node: Files,  Next: Configuration Names,  Prev: Getting Started,  Up: Top
  951.  
  952. Files
  953. *****
  954.  
  955.    As was seen in the previous chapter, the GNU configure and build
  956. system uses a number of different files.  The developer must write a
  957. few files.  The others are generated by various tools.
  958.  
  959.    The system is rather flexible, and can be used in many different
  960. ways.  In describing the files that it uses, I will describe the common
  961. case, and mention some other cases that may arise.
  962.  
  963. * Menu:
  964.  
  965. * Developer Files::        Developer Files.
  966. * Build Files::            Build Files.
  967. * Support Files::        Support Files.
  968.  
  969. 
  970. File: configure.info,  Node: Developer Files,  Next: Build Files,  Up: Files
  971.  
  972. Developer Files
  973. ===============
  974.  
  975.    This section describes the files written or generated by the
  976. developer of a package.
  977.  
  978. * Menu:
  979.  
  980. * Developer Files Picture::    Developer Files Picture.
  981. * Written Developer Files::    Written Developer Files.
  982. * Generated Developer Files::    Generated Developer Files.
  983.  
  984. 
  985. File: configure.info,  Node: Developer Files Picture,  Next: Written Developer Files,  Up: Developer Files
  986.  
  987. Developer Files Picture
  988. -----------------------
  989.  
  990.    Here is a picture of the files which are written by the developer,
  991. the generated files which would be included with a complete source
  992. distribution, and the tools which create those files.  The file names
  993. are plain text and the tool names are enclosed by `*' characters (e.g.,
  994. `autoheader' is the name of a tool, not the name of a file).
  995.  
  996.    acconfig.h       configure.in                 Makefile.am
  997.        |                |                           |
  998.        |  --------------+----------------------     |
  999.        |  |             |                     |     |
  1000.        v  v             |    acinclude.m4     |     |
  1001.    *autoheader*         |         |           v     v
  1002.        |                |         v      --->*automake* 
  1003.        v                |--->*aclocal*   |       |      
  1004.    config.in            |         |      |       v      
  1005.                         |         v      |   Makefile.in
  1006.                         |    aclocal.m4---
  1007.                         |     |
  1008.                         v     v
  1009.                        *autoconf*
  1010.                            |
  1011.                            v
  1012.                        configure
  1013.  
  1014. 
  1015. File: configure.info,  Node: Written Developer Files,  Next: Generated Developer Files,  Prev: Developer Files Picture,  Up: Developer Files
  1016.  
  1017. Written Developer Files
  1018. -----------------------
  1019.  
  1020.    The following files would be written by the developer.
  1021.  
  1022. `configure.in'
  1023.      This is the configuration script.  This script contains
  1024.      invocations of autoconf macros.  It may also contain ordinary
  1025.      shell script code.  This file will contain feature tests for
  1026.      portability issues.  The last thing in the file will normally be
  1027.      an `AC_OUTPUT' macro listing which files to create when the
  1028.      builder runs the configure script.  This file is always required
  1029.      when using the GNU configure system.  *Note Write configure.in::.
  1030.  
  1031. `Makefile.am'
  1032.      This is the automake input file.  It describes how the code should
  1033.      be built.  It consists of definitions of automake variables.  It
  1034.      may also contain ordinary Makefile targets.  This file is only
  1035.      needed when using automake (newer tools normally use automake, but
  1036.      there are still older tools which have not been converted, in
  1037.      which the developer writes `Makefile.in' directly).  *Note Write
  1038.      Makefile.am::.
  1039.  
  1040. `acconfig.h'
  1041.      When the configure script creates a portability header file, by
  1042.      using `AM_CONFIG_HEADER' (or, if not using automake,
  1043.      `AC_CONFIG_HEADER'), this file is used to describe macros which are
  1044.      not recognized by the `autoheader' command.  This is normally a
  1045.      fairly uninteresting file, consisting of a collection of `#undef'
  1046.      lines with comments.  Normally any call to `AC_DEFINE' in
  1047.      `configure.in' will require a line in this file. *Note Write
  1048.      acconfig.h::.
  1049.  
  1050. `acinclude.m4'
  1051.      This file is not always required.  It defines local autoconf
  1052.      macros.  These macros may then be used in `configure.in'.  If you
  1053.      don't need any local autoconf macros, then you don't need this
  1054.      file at all.  In fact, in general, you never need local autoconf
  1055.      macros, since you can put everything in `configure.in', but
  1056.      sometimes a local macro is convenient.
  1057.  
  1058.      Newer tools may omit `acinclude.m4', and instead use a
  1059.      subdirectory, typically named `m4', and define `ACLOCAL_AMFLAGS =
  1060.      -I m4' in `Makefile.am' to force `aclocal' to look there for macro
  1061.      definitions.  The macro definitions are then placed in separate
  1062.      files in that directory.
  1063.  
  1064.      The `acinclude.m4' file is only used when using automake; in older
  1065.      tools, the developer writes `aclocal.m4' directly, if it is needed.
  1066.  
  1067. 
  1068. File: configure.info,  Node: Generated Developer Files,  Prev: Written Developer Files,  Up: Developer Files
  1069.  
  1070. Generated Developer Files
  1071. -------------------------
  1072.  
  1073.    The following files would be generated by the developer.
  1074.  
  1075.    When using automake, these files are normally not generated manually
  1076. after the first time.  Instead, the generated `Makefile' contains rules
  1077. to automatically rebuild the files as required.  When
  1078. `AM_MAINTAINER_MODE' is used in `configure.in' (the normal case in
  1079. Cygnus code), the automatic rebuilding rules will only be defined if
  1080. you configure using the `--enable-maintainer-mode' option.
  1081.  
  1082.    When using automatic rebuilding, it is important to ensure that all
  1083. the various tools have been built and installed on your `PATH'.  Using
  1084. automatic rebuilding is highly recommended, so much so that I'm not
  1085. going to explain what you have to do if you don't use it.
  1086.  
  1087. `configure'
  1088.      This is the configure script which will be run when building the
  1089.      package.  This is generated by `autoconf' from `configure.in' and
  1090.      `aclocal.m4'.  This is a shell script.
  1091.  
  1092. `Makefile.in'
  1093.      This is the file which the configure script will turn into the
  1094.      `Makefile' at build time.  This file is generated by `automake'
  1095.      from `Makefile.am'.  If you aren't using automake, you must write
  1096.      this file yourself.  This file is pretty much a normal `Makefile',
  1097.      with some configure substitutions for certain variables.
  1098.  
  1099. `aclocal.m4'
  1100.      This file is created by the `aclocal' program, based on the
  1101.      contents of `configure.in' and `acinclude.m4' (or, as noted in the
  1102.      description of `acinclude.m4' above, on the contents of an `m4'
  1103.      subdirectory).  This file contains definitions of autoconf macros
  1104.      which `autoconf' will use when generating the file `configure'.
  1105.      These autoconf macros may be defined by you in `acinclude.m4' or
  1106.      they may be defined by other packages such as automake, libtool or
  1107.      gettext.  If you aren't using automake, you will normally write
  1108.      this file yourself; in that case, if `configure.in' uses only
  1109.      standard autoconf macros, this file will not be needed at all.
  1110.  
  1111. `config.in'
  1112.      This file is created by `autoheader' based on `acconfig.h' and
  1113.      `configure.in'.  At build time, the configure script will define
  1114.      some of the macros in it to create `config.h', which may then be
  1115.      included by your program.  This permits your C code to use
  1116.      preprocessor conditionals to change its behaviour based on the
  1117.      characteristics of the host system.  This file may also be called
  1118.      `config.h.in'.
  1119.  
  1120. `stamp.h-in'
  1121.      This rather uninteresting file, which I omitted from the picture,
  1122.      is generated by `automake'.  It always contains the string
  1123.      `timestamp'.  It is used as a timestamp file indicating whether
  1124.      `config.in' is up to date.  Using a timestamp file means that
  1125.      `config.in' can be marked as up to date without actually changing
  1126.      its modification time.  This is useful since `config.in' depends
  1127.      upon `configure.in', but it is easy to change `configure.in' in a
  1128.      way which does not affect `config.in'.
  1129.  
  1130. 
  1131. File: configure.info,  Node: Build Files,  Next: Support Files,  Prev: Developer Files,  Up: Files
  1132.  
  1133. Build Files
  1134. ===========
  1135.  
  1136.    This section describes the files which are created at configure and
  1137. build time.  These are the files which somebody who builds the package
  1138. will see.
  1139.  
  1140.    Of course, the developer will also build the package.  The
  1141. distinction between developer files and build files is not that the
  1142. developer does not see the build files, but that somebody who only
  1143. builds the package does not have to worry about the developer files.
  1144.  
  1145. * Menu:
  1146.  
  1147. * Build Files Picture::        Build Files Picture.
  1148. * Build Files Description::    Build Files Description.
  1149.  
  1150. 
  1151. File: configure.info,  Node: Build Files Picture,  Next: Build Files Description,  Up: Build Files
  1152.  
  1153. Build Files Picture
  1154. -------------------
  1155.  
  1156.    Here is a picture of the files which will be created at build time.
  1157. `config.status' is both a created file and a shell script which is run
  1158. to create other files, and the picture attempts to show that.
  1159.  
  1160.    config.in        *configure*      Makefile.in
  1161.       |                  |               |
  1162.       |                  v               |
  1163.       |             config.status        |
  1164.       |                  |               |
  1165.    *config.status*<======+==========>*config.status*
  1166.       |                                  |
  1167.       v                                  v
  1168.    config.h                          Makefile
  1169.  
  1170. 
  1171. File: configure.info,  Node: Build Files Description,  Prev: Build Files Picture,  Up: Build Files
  1172.  
  1173. Build Files Description
  1174. -----------------------
  1175.  
  1176.    This is a description of the files which are created at build time.
  1177.  
  1178. `config.status'
  1179.      The first step in building a package is to run the `configure'
  1180.      script.  The `configure' script will create the file
  1181.      `config.status', which is itself a shell script.  When you first
  1182.      run `configure', it will automatically run `config.status'.  An
  1183.      `Makefile' derived from an automake generated `Makefile.in' will
  1184.      contain rules to automatically run `config.status' again when
  1185.      necessary to recreate certain files if their inputs change.
  1186.  
  1187. `Makefile'
  1188.      This is the file which make will read to build the program.  The
  1189.      `config.status' script will transform `Makefile.in' into
  1190.      `Makefile'.
  1191.  
  1192. `config.h'
  1193.      This file defines C preprocessor macros which C code can use to
  1194.      adjust its behaviour on different systems.  The `config.status'
  1195.      script will transform `config.in' into `config.h'.
  1196.  
  1197. `config.cache'
  1198.      This file did not fit neatly into the picture, and I omitted it.
  1199.      It is used by the `configure' script to cache results between
  1200.      runs.  This can be an important speedup.  If you modify
  1201.      `configure.in' in such a way that the results of old tests should
  1202.      change (perhaps you have added a new library to `LDFLAGS'), then
  1203.      you will have to remove `config.cache' to force the tests to be
  1204.      rerun.
  1205.  
  1206.      The autoconf manual explains how to set up a site specific cache
  1207.      file.  This can speed up running `configure' scripts on your
  1208.      system.
  1209.  
  1210. `stamp.h'
  1211.      This file, which I omitted from the picture, is similar to
  1212.      `stamp-h.in'.  It is used as a timestamp file indicating whether
  1213.      `config.h' is up to date.  This is useful since `config.h' depends
  1214.      upon `config.status', but it is easy for `config.status' to change
  1215.      in a way which does not affect `config.h'.
  1216.  
  1217. 
  1218. File: configure.info,  Node: Support Files,  Prev: Build Files,  Up: Files
  1219.  
  1220. Support Files
  1221. =============
  1222.  
  1223.    The GNU configure and build system requires several support files to
  1224. be included with your distribution.  You do not normally need to concern
  1225. yourself with these.  If you are using the Cygnus tree, most are already
  1226. present.  Otherwise, they will be installed with your source by
  1227. `automake' (with the `--add-missing' option) and `libtoolize'.
  1228.  
  1229.    You don't have to put the support files in the top level directory.
  1230. You can put them in a subdirectory, and use the `AC_CONFIG_AUX_DIR'
  1231. macro in `configure.in' to tell `automake' and the `configure' script
  1232. where they are.
  1233.  
  1234.    In this section, I describe the support files, so that you can know
  1235. what they are and why they are there.
  1236.  
  1237. `ABOUT-NLS'
  1238.      Added by automake if you are using gettext.  This is a
  1239.      documentation file about the gettext project.
  1240.  
  1241. `ansi2knr.c'
  1242.      Used by an automake generated `Makefile' if you put `ansi2knr' in
  1243.      `AUTOMAKE_OPTIONS' in `Makefile.am'.  This permits compiling ANSI
  1244.      C code with a K&R C compiler.
  1245.  
  1246. `ansi2knr.1'
  1247.      The man page which goes with `ansi2knr.c'.
  1248.  
  1249. `config.guess'
  1250.      A shell script which determines the configuration name for the
  1251.      system on which it is run.
  1252.  
  1253. `config.sub'
  1254.      A shell script which canonicalizes a configuration name entered by
  1255.      a user.
  1256.  
  1257. `elisp-comp'
  1258.      Used to compile Emacs LISP files.
  1259.  
  1260. `install-sh'
  1261.      A shell script which installs a program.  This is used if the
  1262.      configure script can not find an install binary.
  1263.  
  1264. `ltconfig'
  1265.      Used by libtool.  This is a shell script which configures libtool
  1266.      for the particular system on which it is used.
  1267.  
  1268. `ltmain.sh'
  1269.      Used by libtool.  This is the actual libtool script which is used,
  1270.      after it is configured by `ltconfig' to build a library.
  1271.  
  1272. `mdate-sh'
  1273.      A shell script used by an automake generated `Makefile' to pretty
  1274.      print the modification time of a file.  This is used to maintain
  1275.      version numbers for texinfo files.
  1276.  
  1277. `missing'
  1278.      A shell script used if some tool is missing entirely.  This is
  1279.      used by an automake generated `Makefile' to avoid certain sorts of
  1280.      timestamp problems.
  1281.  
  1282. `mkinstalldirs'
  1283.      A shell script which creates a directory, including all parent
  1284.      directories.  This is used by an automake generated `Makefile'
  1285.      during installation.
  1286.  
  1287. `texinfo.tex'
  1288.      Required if you have any texinfo files.  This is used when
  1289.      converting Texinfo files into DVI using `texi2dvi' and TeX.
  1290.  
  1291. `ylwrap'
  1292.      A shell script used by an automake generated `Makefile' to run
  1293.      programs like `bison', `yacc', `flex', and `lex'.  These programs
  1294.      default to producing output files with a fixed name, and the
  1295.      `ylwrap' script runs them in a subdirectory to avoid file name
  1296.      conflicts when using a parallel make program.
  1297.  
  1298. 
  1299. File: configure.info,  Node: Configuration Names,  Next: Cross Compilation Tools,  Prev: Files,  Up: Top
  1300.  
  1301. Configuration Names
  1302. *******************
  1303.  
  1304.    The GNU configure system names all systems using a "configuration
  1305. name".  All such names used to be triplets (they may now contain four
  1306. parts in certain cases), and the term "configuration triplet" is still
  1307. seen.
  1308.  
  1309. * Menu:
  1310.  
  1311. * Configuration Name Definition::    Configuration Name Definition.
  1312. * Using Configuration Names::        Using Configuration Names.
  1313.  
  1314.